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(57) Abstract: A dynamic comparison module implemented as a program executing on a server (e.g., a web server) can dynamically 
compare multiple products having a variety of standard and optional features. Information passed to the dynamic comparison mod- 
ule typically includes a target product identification (representing the main product to be compared) including the target product' s 
configuration (e.g., optional equipment, features include) and one or more competitor product identifications. The identification can 
be as simple as product model number, or can include specific optional desired features, as might be chosen by a user configuring the 
target product. The dynamic comparison module examines how the target product is configured, via the target product information, 
and any standard product information from a product feature database. The dynamic comparison module will then determine what 
product feature categories are included, and use the category information to assemble comparably equipped competitor products for 
comparison. A comparison report is generated and returned to a user. 
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SYSTEM AND METHOD FOR DYNAMIC PRODUCT COMPARISON 



BACKGROUND OF THE INVENTION 
Field of the Invention 

5 This invention relates to systems and methods for comparing products, and 

particularly to systems and methods for comparing automobiles, including their 
specifications, features, and prices using computer systems in a client/server 
environment. 

Description of the Related Art 

10 As more users begin to take advantage of businesses which use the Internet 

and the World Wide Web (the "web") to describe, market, sell, and deliver products 
and services, competition among those businesses is becoming more fierce. In 
response, many businesses that use the Internet have become more sophisticated in the 
marketing features that they provide users. 

15 For example, a variety of companies provide web sites (e.g., web server 

applications running on server computer systems) that will, given a particular product 
request by a user, search among the many Internet based sellers of that particular 
product to provide price comparisons. Some services (distributed in various media 
including print and electronic) provide more detailed comparisons of similar products 

20 offered by either the same or different manufacturers. The ability to perform these 
product comparisons dynamically, that is quickly enough to formulate and distribute 
from a website in "real-time," is a very beneficial marketing tool for Internet 
businesses. 

Unfortunately, the ability to perform cross-product comparisons is generally 
25 limited by the number of, and variability of product features. This problem is 
particularly noticeable when trying to compare two or more automobiles. 
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Automobiles traditionally have detailed specifications (i.e., the values for particular 
attributes common to all automobiles including engine size, number of cylinders, 
horsepower, torque, dimensions, etc.), and hundreds of distinguishing features which 
can be either standard or optional. However, a feature that is standard or optional on 
5 one automobile, might be standard, optional, or unavailable on another automobile 
that is the target of comparison. Moreover, one of the most important points of 

« 

comparison for consumers is product price, and determining the prices of comparably 
equipped cars requires pricing information about the features, pricing information 
about option packages that combine one or more features, and knowledge of the 
10 contents of various option packages so that the most reasonable and comparably 
priced set of option packages can be considered (e.g., eliminating duplication of 
features, considering mutually exclusive features, considering discounted packaged 
feature sets, etc.). 

Accordingly, it is desirable to have a dynamic product comparison system and 
1 5 method that can perform product comparisons based on many product specification 
values and standard, optional, and unavailable product features. Additionally, such a 
dynamic product comparison system and method should include the ability to consider 
and compare products that are configured and priced (i.e., the process of determining a 
price for a product) based on feature packages that may differ significantly in their 
20 content, logic, and pricing from product to product, both within one and across many 
manufacturers. 

SUMMARY OF THE INVENTION 

It has been discovered that a dynamic comparison module implemented as a 
program executing on a server (e.g., a web server) can dynamically compare multiple 

25 products having a variety of standard and optional features. Information passed to the 
dynamic comparison module typically includes a target product identification 
(representing the main product to be compared) including the target product's 
configuration (e.g., optional equipment, features included) and one or more 
competitor product identifications. The identification can be as simple as product 

30 model number, or can include specific optional desired features, as might be chosen 
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by a user configuring the target product. The dynamic comparison module examines 
how the target product is configured, via the target product information, and any 
standard product information from a product feature database. The result of the 
examination is a specific subset from a standardized set of categories, which represent 
5 vehicle contents universally. Based on the product feature categories included in the 
target vehicle, the dynamic comparison module uses the category information and a 
set of rules and algorithm to assemble comparably equipped competitor products for 
comparison. A comparison report is generated and returned to a user. 

Accordingly, one aspect of the present invention provides a method for 
1 0 producing a comparison of a target product with a competitor product, the comparison 
opefrable to be provided by a program executing on a server computer system to a 
client computer system. A request for comparison including a target product 
identification and a competitor product identification is received from the client 
computer system. A target product configuration is determined from the target 
1 5 product identification. A product feature category is identified corresponding to the 
product configuration. A competitor product configuration corresponding to the 
product feature category is formed. The target product configuration and the 
competitor product configuration are sent to the client computer system. 

In another aspect of the invention, a product comparison system operable to 
20 receive, from a client computer system, a request for comparison including a target 

product identification and a competitor product identification, the product comparison 
system includes a dynamic comparison module and a configuration engine. The 
dynamic comparison module is operable to determining a target product configuration 
from the target product identification and identify a product feature category 
corresponding to the product configuration. The configuration engine is operable to 
form a competitor product configuration corresponding to the product feature 
category. 



WO 01/75729 



PCT/US01/10248 



BRIEF DESCRIPTION OF THE DRAWINGS 

The present invention may be better understood, and its numerous objects, 
features, and advantages made apparent to those skilled in the art by referencing the 
accompanying drawings. 

5 Figure 1 illustrates a client/server computing environment utilizing a dynamic 

comparison module. 

Figure 2 is a flow chart illustrating one possible implementation of a dynamic 
comparison module. 

Figure 3 is a flow chart illustrating one possible implementation of a process 
1 0 for configuring competitor products. 

Figure 4 is a flow chart further illustrating the process for configuring 
competitor products shown in Figure 3. 

Figure 5 is a sample product comparison report generated by the systems and 
methods disclosed herein. 

15 DETAILED DESCRIPTION 

Client/server computer systems operating in a distributed computing 
environment (e.g., web client/server computer systems) are routinely used for product 
research purposes to generate business or business leads for a variety of enterprises. 
One specific example of this type of business activity is providing comparative 
20 automobile information to, and generating leads from users of a web based automobile 
information site. (The focus throughout this application will be on automobile 
business applications, but those having ordinary skill in the art will readily recognize 
the applicability of many of the described techniques to a variety of different fields of 
business and both web-based and non-web-based client/server activities in general.). 

25 Figure 1 illustrates a client/server computing environment for providing 

automobile product information to users via, for example, an interactive web site, and 
utilizing a dynamic product comparison system. Server 100 is typically a web server 
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including the necessary hardware and software to serve hypertext markup language 
(HTML) documents, associated files, and scripts to one or more client (typically web 
client) computer systems 150 when requested by a user of, or an autonomous program 
executing on a client computer system. Client computer systems 150 typically utilize 
5 HTML browsers to display the HTML documents, and to generally interact with 
server 100. As illustrated, server 100 and clients 150 are coupled to each other 
through a communications network 140, such as the Internet. Server 100 and clients 
150 can alternately be coupled to each other through point-to-point connections, or 
dedicated connections. Server 100 is typically an Intel Pentium-based or RISC based 
10 computer system equipped with one or more processors, memory, input/output 
interfaces, a network interface, secondary storage devices, and a user interface. 

Server 100 is a product server in that it typically includes one or more product 
applications executing on the server hardware, for example an automobile information 
and marketing application. Product applications provide users, through common web 

15 serving software, with functionality and content for different products. As illustrated, 
server 100 can serve both web and product server applications. For example, one 
server computer system can execute one or more separate processes for automobile 
information and marketing applications while also executing one or more processes 
specifically for serving web content to user client computer systems 150. Alternately, 

20 the product server applications and any web server applications can each execute on a 
separate computer system. Or, there can be some combination of the two approaches. 
Thus, product server 100 is merely illustrative of web/product server schemes. 

Server 100 includes two applications in addition to web serving functionality: 
dynamic comparison module (DCM) 110, and optimal configuration and pricing 

25 engine 120. Each of server 100, DCM 110, and pricing engine 120, are coupled to 
and communicate with product database 130, which typically holds product feature 
data, along with other data necessary for implementing the product comparison 
system. Although DCM 110, and pricing engine 120 are illustrated as part of (e.g., 
applications executing on) server 100, each of the applications can reside on a 

30 separate application server, or various ones of the applications can be implemented on 
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a single server. The applications can be based on many standard programming 
languages/architectures, such as C++, Java, the common gateway interface (CGI), 
Active Server Pages (ASP), J script, etc. Moreover, although product database 130 is 
illustrated as a separate entity, it too can also be combined with one or more of server 
5 100, DCM 110, and pricing engine 120. The database(s) used, and the database 
management system (DBMS) used to allow access to and control of the database(s) 
can be based on a variety of database schemes, but are typically relational in nature, 
for example structured query language (SQL) databases and DBMSs. 

Dynamic comparison module (DCM) 110 receives product comparison 
10 requests and performs much of the work to form the comparison, as will be described 
in conjunction with Figure 2 below. Using information from product database 130, 
DCM 110 translates standard and optional equipment/features from the target product 
into normalized categories. Once DCM 110 has developed the set of product feature 
categories (based on the target product feature set) to use for the configuration of a 
15 competitor product, that information is passed to optimal configuration and pricing 
engine 120, which will be described in conjunction with Figures 3 and 4 below. 
Pricing engine 120 attempts to configure the competitor automobile covering all of the 
categories which represent features (standard and optional) specified by the 
information included in the initial request. The configuration is performed in order to 
20 optimize the price of the comparably configured automobile, so as to provide the user 
with a fair, more direct, "apples~to-apples" comparison. 

Note that in a typical implementation, a user will choose the target product, 
such as a particular automobile make, model, and trim line, including any optional 
features. The user also typically selects one or more automobiles to be compared with 
25 the target automobile. Alternately, an automobile information and marketing 

application generally, or some specific module (including, for example, DCM 110) 
can suggest competitor models (either from the same manufacturer or another 
manufacturer) that will be the subject of the comparison. 

Proper system function depends, in part, on a flexible and sophisticated 
30 scheme for categorizing and storing automobile information. Database 130 includes 
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specification information (e.g., specification fields and values) for a variety of 
automobiles. Additionally, the database implements a categorization scheme for 
assigning category information to standard and optional features (and potentially 
specifications). In general, standard and optional equipment and features are 
5 converted to normalized categories, which are consistent from automobile to 

automobile. The categories provide the common basis for "translating" the features 
and options of a target automobile into the features and options of competitor 
automobile(s). 

For example, one or more optional features can be termed a package. The 
10 package may comprise sub-packages, or may be a single item. For some automobiles, 
a feature that is optional (and therefore available in a package) could be a standard 
feature in another automobile. A category's descriptive value, for example, how 
finely it is able to grade a particular feature (e.g., anti-lock brakes vs. 4 wheel anti- 
lock brakes), can be based on a set of categories defined with all automobile products 
15 in mind. However, the categories used are preferrably determined (at least in part) by 
the descriptive information about the automobile provided by the manufacturer. In 
this way, categories are more closely tailored to the actual features in products, and 
therefor, they more accurately describe the product. Additionally, this approach is 
convenient for retaining and indexing the descriptive information available for the 
20 product. 

For example, if a manufacturer describes an optional stereo system as "6 
speaker, AM/FM radio with 12 station presets, integrated cassette player with auto- 
reverse, and a trunk mounted 6 CD compact disc changer featuring 4-time 
oversampling," numerous categories and sub-categories (and even sub-categories to 

25 sub-categories) can be derived from this description (if they are not already available 
for use in the system, or if existing categories do not possess sufficient subject matter 
granularity). Moreover, the descriptive text can be saved in the database, with each of 
the category entries pointing back to the descriptive text as a whole. Consequently, a 
package is sufficiently objectified to allow for flexible comparisons, while the 

30 potentially more subjective description of that same package is readily accessible for 
use. 
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In the case of automobiles, many different categories (or major categories) and 
sub-categories can be used. Example major categories include: Anti-theft and Locks; 
Braking and Traction; Doors; Electrical; Engines and Emissions; Entertainment, 
Communications, and Navigation; Exterior, Design, Paint, and Finish; Exterior 
5 Lighting; Heating, Ventilation, and Air Conditioning; Interior Lighting; Interior 

Design, Decor, and Floor Covering; Remote Controls and Remote Releases; Safety; 
Seats; Steering; Storage; Sunroof/Moonroof and Removable/Convertible Tops; 
Towing/Trailering and Payload; Transmissions; Wheels and Tires; and Windows and 
Mirrors. 

10 Taking the major category Anti-theft and Locks as an example, Table 1 

illustrates a number of possible sub-categories, the criteria that can be considered for 
each, definitions that can be used to apply the categories to actual product 
descriptions, and sample product description text. 



Table 1 



Category 



Criteria 



Definitions 



Sample Text 



Vehicle Anti-theft Type of alarm (e.g. horn; Any type of theft deterrent system Pass-Key III Theft Deterrent System 

lights); ignition or engine protecting the entire vehicle Monitors All Doors and Trunk, Activates 

immobilizer; motion Flashing Lights and Horn, Uses Encoded 

sensors; Pellet In Ignition To Detect Mismatch and 

Shut Down Fuel and Starter Systems 



Radio Anti-theft 


Describe alarm or other 
functionality 


Any type of theft deterrent system 
protecting just the radio 


Theftlock Radio Anti-Theft System 
Includes Anti-Theft Coding and 
Removable Control Panel 


Vehicle Theft 
Tracking/Notification 


None 






Break Resistant 
Security Glass 


None 


Functioning as an anti-theft 
device, not related to safety 


Break Resistant Security Glass Features 
Layers of Glass and Impact Resistant 
Polymers To Protect Against Unwanted 
Intruders 


Wheel Locks 


None 


A special lugnut that can not be 
removed without a key 


Wheel Locks 


Locking Pickup 
Truck Tailgate 


None 


On trucks, a tailgate that can be 
locked 


Locking Tailgate With Key Cylinder 


Power Decklid or 
Tailgate Lock/Unlock 


None 


Locks and unlocks a decklid or 
tailgate, but doesn't function as a 


Power Decklid Locks/Unlocks Up To 33 
Feet Away Via Remote Keyless Entry 



release (meaning it doesn't pop 
open the trunk) 

Valet Lockout Lockable items (e.g. A system that restricts a valet to 

glovebox; trunk; console) unlocking the door and starting 
the vehicle by locking other 
components or sections of a 
vehicle via a separate key or 
keyfob function (e.g. trunk, glove 
box) 



Valet Parking Security Locking For Trunk 
and Glove Compartment 
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Power Door Locks None Electronically operated door locks Programmable Power Door Locks On 

Front Doors, Side Doors and Liftgate With 
Illuminated Controls and Autolock 
Function That Locks All Doors When 
Vehicle Exceeds 5-MPH 

Selective Applicable doors; Provides the driver with a choice Selective Locking/Unlocking System 

Locking/Unlocking description of of which doors can be opened Locks/Unlocks Driver Door Only Or All 

functionality Doors Including Liftgate Up To 33 Feet 

Away Via Remote Keyless Entry 

Locking Fuel Filler Identify if key or power Uses a key or remote to lock and Fuel Filler Door Locks Via Power Central 

Door or Cap (remote release inside car unlock Locking System 

not this category) 

Heated Exterior Door None Electronically heated to melt ice Heated Exterior Door Locks On Front 

Locks and prevent it from forming Doors Only 

Child Safety Door None Prevents the passenger doors from Child Proof Sliding Side Door Locks 

Locks being opened from the inside 

Vehicle Anti-Lockout None Any device that prevents the Vehicle Anti-Lockout Feature Prevents 

Device operator from being locked out of Driver Door From Locking If Key Is Left 

the vehicle In Ignition 

Those having ordinary skill in the art will readily recognize that the 
information in Table 1 is merely illustrative, and a wide variety of categories and 
criteria can be implemented, depending, in part, on the type of products and product 
features being categorized. In this example, each of the sub-categories are explicitly a 
5 member of the Anti-theft and Locks category. Other information can be associated 
with categories, such as flags (category is a major category), identification numbers, 
category and sub-category codes, etc. For example, a complete set of category 
information can include: a system category identification, one or more usage flags, a 
major category code, one or more sub-category codes, a description, a research flag, a 
1 0 major category flag, an alphanumeric category name, and a numerical value 
representing the category's level (major, sub, sub-sub, etc.). 

In general, each piece of descriptive text, whether related to standard or 
optional features or equipment, that is maintained has one associated major category, 
and at least one associated subcategory. Because packages can have descriptive text 

15 which is wide-ranging as to content, and because packages can include other packages 
(e.g., the sport package includes the performance package and the entertainment 
package), each package can be associated with one or more major categories, and one 
or more sub-categories as well. Thus, it is convenient to associate a string of one or 
more category bits (CatBits) with each package (and possibly each piece of descriptive 

20 text, feature and specification) indicating that some part of the package corresponds to 
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a particular category. For example, each piece of descriptive text, whether for a 
standard or optional feature, can have its own CatBits describing the categories 
represented. Many packages are combinations of optional features, and so the CatBits 
for a package can be constructed by logically OR'ing all of the CatBits for the 
5 package's constituent features. The CatBits provide a convenient and efficient way to 
compile features and packages, and make desired comparisons. 

This data organizing scheme provides the framework for implementing the 
dynamic comparison system. 

Figure 2 is a flow chart illustrating one possible implementation of a dynamic 
10 comparison module (DCM). The process begins at 200 where the DCM receives a 
comparison request from a user (typically via the web server software, and possibly 
another application layer). Where the DCM is implemented as a CGI script or as 
ASP, Table 2 lists example form variables that get passed or posted to the DCM. 

Table 2 

Variable Description 

TargModlCd This is the main/target vehicle identification code. It is the car that the 

competitors are compared against, and has a recognized value in the 
database. 

ComprsModlCd This is the competitor list vehicle identification codes, typically delimited 

by A . All competitor vehicles must recognized value in the database. The 
number of allowed competitors can be established by the DCM. 

ComprsSegmentCd This is the segment code, winch is optionally used to specify a set of 

attributes to be reported on. The segment codes help to make reports more 
specific to the type of car that is being reported on. 

This is the packages string (using recognized or initially unrecognized 
package codes) delimited by A . 

This is the model year of the target vehicle. 

This is the descriptive name of the target vehicle. 

This is the target vehicle's combined MSRP and destination price. 

This is the target vehicles combined MSRP and destination price. 

This is an additional footnote field that when populated is added to the end 
of the report. 



OptnString 

ModlYrNbr 

PVCDesc 

MSRPBaseAmt 

TotMSRPAmt 

AddtlFootnote 
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RptTypeCd 


This is the report type field. This field give the flexibility of multiple report 




types. 


WebSiteld 


This is the Site origin code. It can be used to further customize your report 




or for logging purposes. 


CntryCd 


This is the Country Code. It can be used to further customize your report or 




for logging purposes. 


LangCd 


This is the Language Code. It can be used to further customize your report 




or for logging purposes. 



Note that much of the information typically sent to the DCM is used for 
administrative purposes, such as logging comparison requests, and formatting the 
reports. 



Once this information is received, the DCM prepares (210) a variety of support 
5 data structures, including bit strings (similar to CatBit strings) and arrays. For 
example, if target marketing segments are going to be used to modify the way in 
which vehicles are compared, CatBit strings which represent typical equipment levels 
for vehicles in the target segment are generated and/or loaded. Next, if the package 
codes that are supplied are not in a familiar format, an exception array is created 

10 containing relationships between the unfamiliar package codes and predetermined 
package codes present in the database. Also at this time, an array of mutually 
exclusive categories is created. For example, a configured car can have only one 
transmission, and so if the user is allowed to select both manual and automatic, or if 
there is a standard transmission, but the user picks an optional transmission for the 

15 target automobile, there should to be a mechanism for testing the aggregate CatBits 
for mutually exclusive categories so that the conflict to be resolved. Note that vehicle 
manufacturer rules for less obvious feature incompatibilities are built into the product 
information database. The array of mutually exclusive categories, or the DCM itself 
can include logic for resolving the conflict. For example, if one of the categories is 

20 part of an option package selected by the user, that would supercede the standard 

equipment category. Other types of support information, or product information not 
available from database 130 can also be utilized in this manner. 
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At 220, the existence of a package exception is tested. Package exceptions 
occur, for example, when a package code is sent to the DCM, and the vehicle 
identification code matches the trim identification codes already in the database, but 
the package code is listed under an unfamiliar code. If such an exception occurs, the 
5 package code is converted to a recognized or predetermined package code (225), 
otherwise, the code is left alone. 

At 230, product features for either or both the target automobile and the 
competitor automobile(s) are gathered from database 130 based on standard features 
for the particular automobiles, and based on the options specified for the target 

10 automobile. In step 240, the feature information is reduced to category information, 
and particularly CatBits for the respective automobiles. Whether segments are being 
used is determined in 250. If so, the segment CatBits are logically ANDed with the 
target CatBits to modify the information that will be used to configure competitor 
automobiles. In 260, the remaining CatBits are cross-checked for conflicting or 

15 mutually exclusive categories, and modified accordingly. Next, in 270, the competitor 
products are configured. This typically involves sending the final target CatBits and 
one or more ComprsModlCd values to the optimal configuration and pricing engine 
120, as will be described below in greater detail. When competitor configuration 
information is returned from engine 120, it is used along with other information (e.g., 

20 values of some of the variables initially passed to DCM 110) to produce the 

comparison report which is returned (280) to the user in the form of HTML code 
viewable on a browser executing on client 150. Other modes of returning comparison 
information, for example Extensible Markup Language (XML) code, can be used. A 
sample comparison report is shown in Figure 5. 

25 Figure 3 is a flow chart illustrating one possible implementation of a process 

270 for configuring competitor products. This process is performed by optimal 
configuration and pricing engine 120. The goal of process 270 is to find the optimal 
permissible combination of competitor automobile packages which satisfies the total 
feature coverage of the target automobile CatBits, where "optimal" is based on 

30 accomplishing category coverage for the lowest price. In some cases, it may not be 
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possible to cover all target automobile CatBits, i.e., some features may not be 
available for a particular competitor automobile, or requested features may produce 
conflicts. Additional logic can be included to accommodate these circumstances. For 
example, where a feature is not available for a particular competitor automobile, there 
5 can be suggested similar features, or simply an indication that the feature is not 

available, or a standard adjustment to the price representing the fair market value of 
the missing feature may be noted. Where requested features produce conflicts, these 
conflicts can be handled in a manner similar to that for handling target vehicle CatBit 
conflicts, as previously described in conjunction with step 260 of Figure 2. In some 
10 instances, a conflict or unavailable feature may be so significant, that an error 

condition is caused, and it is reported to the user that a comparison could not (or could 
no adequately) be made. 

In 300, CatBits, and competitor trim information are received by engine 120. 
Standard and unavailable CatBits are removed (310) from the target CatBit set, and 

15 will not be considered, because they will not be in an option package. Moreover, only 
the categories for option packages which are available and not yet part of the 
configuration need be considered. In 320, all possible traces pertaining to option 
packages covering the requested categories for each particular competitor automobile 
are gathered. Traces are used to describe all of the possible ways in which option 

20 packages (and thus the features they contain) can be purchased for the competitor 

automobile. A trace is a data structure used to construct optimal competitor product 
configurations. Traces contain some or all of the information shown in Table 3. 



Table 3 


Trace Contents 


Description 


BasePkgID (string) 


Package code for package that starts the trace. 


System Pkg ID 


Database system identification for above package. 


(unsigned long) 




NA Pkgs (string list) 


Packages not available (NA) with this trace. Each element in the list is one 




of the permutations of the NA Logic. For example: NA (A & .(B | C)) 




results in two elements (1) :A:B: and (2) :A:C: 
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Free Pkgs (string) 


Packages included in the base part of this race (ex: :A:B:) 


General Logic (string) 


Text of general logic for base part. 


Price Logic (string) 


Text of price logic for the trace 


Base CatBits (binary 


Category bits for base part of trace. 


array) 




Required Traces 


Required Packages for tins base package. (May have none.) These are 




traces themselves. 


List Price (long) 


MSRP for base part of trace. 


Invoice Price (long) 


Invoice for base part of trace 


Total List Price (long) 


Total list price of base and all branches 


Total Inv Price (long) 


Total invoice price of base and all branches 


Total CatBits (binary 


Total category bits of base and all branches 


array) 





Because an option package can include one or more categorized features, a 
package trace can represent one or more categorized features, and can include logical 
dependencies to one or more packages (and its/their associated traces). A particular 
option package is "fully traced" when a trace has been created for each way the option 
5 package can be purchased. Traces and the process of fully tracing a package account 
for the fact that a package can have multiple prices and multiple logic dependencies 
based on purchasing it in the presence or absence of other packages. For example, 
package A might cost $500 when purchased alone, but cost only $300 when purchased 
with package B or C. Similarly, logical relationships (e.g., package B requires 
10 package D) must also be taken into consideration. Thus, providing an exhaustive list 
of possible trace combinations and dependencies (i.e., folly tracing a package) is a 
necessary first step in determining the optimal competitor automobile configuration. 

As can be imagined, the set of all possible combinations of packages that 
satisfy a set of features (as represented by categories) can be very large. Accordingly, 
15 several techniques are used to reduce the set of all possible traces, once that set is 
formed, prior to testing combinations of traces to reach an optimal solution. These 
"trace reduction" techniques utilize the CatBit string associated with each trace. That 
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10 



15 



CatBit string covers all constituent packages and features implicated (via the logic 
information stored in the trace) by the package in question. 

Not all traces associated with a particular competitor automobile trim line 
represent a package that includes a required feature, that is, not all traces satisfy a 
target CatBit. Consequently, all traces that contain no target CatBit are removed in 
330. Next, the traces are grouped into columns (340) based on the CatBit satisfied by 
the trace. Thus, the first column contains a list of all traces that satisfy the first 
CatBit, and so forth. Since a particular trace might represent a package (or packages) 
that satisfies more than one CatBit, traces can appear in many different columns. 
Within each column, the list of traces is preferably maintained in order of increasing 
price. Reduction steps 350, 355, and 360 are repeated until one pass through all three 
steps fails to remove a trace (370). Column reduction 350 is performed when an 
entire column can be removed. The general rule is that if column X is a subset of 
column Y, then column Y can be removed from the set of traces. Table 4 illustrates 
an example. 

Table 4 



Column 0 



Column 1 



Column 2 



20 



Air Conditioning (AC) Power Windows (PW) Cruise Control (CC) 
Trace 1 Trace 2 Trace 3 

Trace 2 Trace 4 Trace 6 

Trace 4 
Trace 5 

Given the situation illustrated above, it is clear that an optimal solution must have 
either Trace 2 or Trace 4, since that is the only way to satisfy the power windows 
requirement. But because both Trace 2 and Trace 4 include the air conditioning 
option, we can eliminate column 0. That is, any solution that includes PW must 
include AC, and so AC can be eliminated from the analysis. 

"Not Available" (NA) reduction 355 removes individual traces based on two 
different rules. First, if a column contains only one trace TX, all other traces which 
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are not available with TX can be removed (because TX is absolutely required). 
Second, if all the traces in column X contain a common NA package, then any traces 
containing that package can be eliminated. 

"Common Includes" (CI) reduction 360 removes individual traces based on 
5 one rule. If all of the traces in a given column share some CatBits from the unique 
CatBits set (the unique CatBits set is a subset of all of the CatBits used in 270, and 
can only occur at most once during the combination of traces, e.g., a car can only have 
one air conditioning system) in common in their included CatBits, then in columns 
other than the given column, any traces which include any of these CatBits at their 
10 root level can be eliminated. So, if all of the traces in column X contain air 

conditioning, then any traces in other columns containing air conditioning cannot be 
added to any of the traces from column X, one of which must be in the solution. 

When a pass through steps 350, 355, and 360 yields no trace removal, 
operation moves to 380, where all possible trace combinations are tested 380. Once 
15 the best combination is found, it is returned to the comparison step, 280. 

Figure 4 is a flow chart further illustrating the test possible combinations step 
380. In 400, the remaining reduced columns are arranged in order of increasing 
number of traces, for example the right-most column has the most traces. 
Combinations of traces (one from each column) are assembled in a piece-wise fashion 
20 based on a depth- first (i.e., preferentially iterate through complete combinations of 
traces by iterating through the right-most traces first) search algorithm starting from 
left and moving right. This strategy is used because the "nesting" level increases 
moving toward longer lists. Consequently, the nth list should be iterated before the 
(n-l)th list. So, for a particular trace examined beginning at 410, if the column to 
which the particular trace belongs is already satisfied (415) (i.e., that column's CatBit 
is covered by a trace in a previous column), then the current column is skipped (420). 

If not, then 425 tests for a combination rule violation. In general, a variety of 
combination rules can be applied, and for the rules described below, the following 
notation applies. 
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Tables 



Notation 


Description 


Ar>B 


Package code for package that starts the trace. 




Package A requires packages B and C. 


=>C 




A :=> B => C 


Package A requires package B, which, in turn 




requires C. 


A(B) 


Package A includes B free of charge (as part of Base 




01 J\) 


Al vs. A2 


Different "flavors" of packages can be described 




using this shorthand. It means that both traces start 




with A but require different packages. 


A (NA w/B) 


A is Not Available with B. 


A [AC, PW] 


A covers Air Conditioning and Power Windows. 



"Starts with X" Rule: If a trace includes package X, do not add any traces 
starting with X to it. Thus, the following combination is illegal: {A B => C} + {B 
=>C}. 

5 "NA" Rule: If two traces contain conflicts between one's "NA" list and the 

other's included and required packages, do not combine them. The following 
combination is illegal: {A => B (NA w/D) => C} + {D => C}. 

"Same Branch" Rule: When combining two traces, truncate any "requires" 
branches from the second trace which are already required in the original trace. For 

1 0 consistency, always truncate the trace on the right. These branches must correspond 
to the same "flavor" of the package. That is, the branches must be equivalent from the 
comparison points to their respective ends. Assuming the rest of the rules are 
satisfied, this combination is legal and would remove the Bl branch from Dl : 
{Al =>B1^C} + {D1=>B1:=>C}. However, this combination is illegal since 

15 there are different flavors of B: {Al => Bl => C} + {D2 => B2 => E}. 

"Unique Includes" Rule: If two traces, applying the rules above, contain 
intersecting unique CatBit sets anywhere in their totality of branches, they cannot be 
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combined. The following combination is illegal since both traces satisfy air 
conditioning (AC): {A => B [AC]} + {D ^> E [AC]}. 

If there is a rule violation for the particular trace, the next trace is selected 
(430) and operation returns to 410. Also, if operation of a rule requires modification 
5 prescribed by the rale, that modification is performed. If there is no rule violation, or 
rule effect, then the total price of all traces along the current path is compared to 
current lowest (best) price solution. If the current path price is higher than the current 
best price solution, operation proceeds through 430 and 410. If not, the current trace 
is accumulated (440). If operation is not in the last column (445), then operation 

10 proceeds to the next column (420). If operation is in the last column, 455 tests to 

determine if the current combination is the best combination. If so, that combination 
is saved, and the process moves to step 465, if not the process moves to step 465 
without saving the current combination. If there are no further possible combinations 
to be examined, the best combination is returned (480). If additional combinations 

1 5 remain, operation moves to 470 where the most recently accumulated trace is 

removed, and subsequent traces in the same column are examined, or if necessary, 
further un-accumulation is performed and operation resumes at a previous column. 

The flowcharts of Figures 2, 3, and 4 merely illustrate possible examples of 
the dynamic comparison system implementation, and those having ordinary skill in 
20 the art will readily recognize a variety of equivalent alternatives. Additionally, these 
processes can be iterated, for successive competitor automobiles, or multiple 
competitor automobiles can be configured simultaneously, depending upon the 
implementation. 

As mentioned above, Figure 5 illustrates a possible comparison report 
25 returned by DCM 110. The report 500 lists features 510 and specifications 515 for a 
target automobile 520 and a competitor automobile 530. In most cases, the two (or 
more) products being compared will have some differences. For example, daytime 
running lamps are not available (534) for competitor automobile 530. Also, many 
features of competitor automobile 530 are optional (532) and thus add to the base 
30 MSRP. The fact that there is some additional cost that would be associated with 
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adding features that are not available (e.g., in the after-market) is illustrated at 536. 
Many additional report elements can be included in report 500. For example, features 
that are optional can also be listed by the package that provides them at the best value. 
Unavailable features could include a suggested alternative. Pricing and package logic 
5 which impacted the optimal result could be provided in detail. In general, any 
information that would aid the comparison can be included in report 500. 

The description of the invention set forth herein is illustrative and is not 
intended to limit the scope of the invention as set forth in the following claims. 
Variations and modifications of the embodiments disclosed herein maybe made based 
10 on the description set forth herein, without departing from the scope and spirit of the 
invention as set forth in the following claims. 
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WHAT IS CLAIMED IS: 

1 . A method for producing a comparison of a target product with a competitor 
product, the comparison operable to be provided by a program executing on a server 
computer system to a client computer system, the method comprising: 

receiving, from the client computer system, a request for comparison including 
5 a target product identification and a competitor product identification; 

determining a target product configuration from the target product 
identification; 

identifying a product feature category corresponding to the product 
configuration; 

10 forming a competitor product configuration corresponding to the product 

feature category; and 
sending the target product configuration and the competitor product 
configuration to the client computer system. 

2. The method of claim 1 wherein the target product identification further 
1 5 comprises a target product identification code and a target product feature option 

package. 

3. The method of claim 2 wherein the determining further comprises 
associating a predetermined product feature option package with the target product 
feature option package, wherein the product feature category corresponds to the 

20 predetermined product feature option package. 

4. The method of claim 3 further comprising: 

forming an array of a plurality of target product feature option packages and a 
corresponding plurality of predetermined product feature option 
packages, wherein the associating further comprises comparing the 
25 target product feature option package with the plurality of target 

product feature option packages of the array. 
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5. The method of claim 1 wherein correspondence of the product feature 
category to the product configuration is represented by a bit value in a bit string. 

6. The method of claim 1 wherein the target product configuration 
corresponds to a plurality of product feature categories, and wherein correspondence 

5 of the plurality of product feature categories to the target product configuration is 
represented by a corresponding plurality of bit values in a category bit string. 

7. The method of claim 6 further comprising: 

forming a product segment bit string, the product segment bit string including 
at least one bit value corresponding to at least one of the plurality of bit 
1 0 values in the category bit string, the at least one bit value indicating 

that a corresponding category is a valid category for comparison. 

8. The method of claim 7 further comprising: 

performing an AND operation between the category bit string the product 

segment bit string, the AND operation producing a modified category 
1 5 bit string, wherein the modified category bit string is used for the 

forming a competitor product configuration. 

9. The method of claim 6 further comprising: 

comparing at least two of the plurality of bit values in the category bit string to 
determine if they indicate conflicting product feature categories. 

20 10. The method of claim 9 further comprising: 

forming an array of a plurality conflicting bit values, each of the conflicting bit 

values having a corresponding precedence; and 
changing, when it is determined that the at least two of the plurality of bit 
values in the category bit string indicate conflicting product feature 
25 categories, the bit value of one of the at least two of the plurality of bit 

values depending on the corresponding presidencies of the at least two 
of the plurality of bit values. 
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1 1 . The method of claim 6 wherein at least one of the plurality of bit values in 
the category bit string is determined by at least one of a product feature option 
package and a standard product feature. 

12. The method of claim 1 wherein the forming a competitor product 
5 configuration further comprises: 

selecting at least one competitor product feature option package. 

13. The method of claim 12 wherein the selecting is optimized according to at 
least one of competitor product feature option package price and competitor product 
feature option package content. 

10 14. The method of claim 1 wherein the sending the target product 

configuration and the competitor product configuration to the client computer system 
further comprises: 

forming hypertext markup language output based on the target product 
configuration and the competitor product configuration. 

15 15. The method of claim 1 encoded in a computer readable medium as 

instructions executable on a processor, the computer readable medium being one of an 
electronic storage medium, a magnetic storage medium, an optical storage medium, 
and a communications medium conveying signals encoding the instructions. 

16. The method of claim 1 wherein the target product is an automobile and the 
20 competitor product is an automobile. 

17. A product comparison system operable to receive, from a client computer 
system, a request for comparison including a target product identification and a 
competitor product identification, the product comparison system comprising: 

a dynamic comparison module operable to determining a target product 
25 configuration from the target product identification and identify a 
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product feature category corresponding to the product configuration; 
and 

a configuration engine operable to form a competitor product configuration 
corresponding to the product feature category. 

5 18. The product comparison system of claim 17 wherein the target product 

identification further comprises a target product identification code and a target 
product feature option package. 

19. The product comparison system of claim 17 wherein correspondence of 
the product feature category to the product configuration is represented by a bit value 

10 in a bit string. 

20. The product comparison system of claim 17 wherein the target product 
configuration corresponds to a plurality of product feature categories, and wherein 
correspondence of the plurality of product feature categories to the target product 
configuration is represented by a corresponding plurality of bit values in a category bit 

15 string. 

21. The product comparison system of claim 20 wherein the dynamic 
comparison module is further operable to form a product segment bit string, the 
product segment bit string including at least one bit value corresponding to at least 
one of the plurality of bit values in the category bit string, the at least one bit value 

20 indicating that a corresponding categoiy is a valid category for comparison. 

22. The product comparison system of claim 21 wherein the dynamic 
comparison module is farther operable to perform an AND operation between the 
category bit string the product segment bit string, the AND operation producing a 
modified category bit string, wherein the modified category bit string is used to form a 

25 competitor product configuration. 

23. The product comparison system of claim 20 wherein the dynamic 
comparison module is further operable to compare at least two of the plurality of bit 
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values in the category bit string to determine if they indicate conflicting product 
feature categories. 

24. The product comparison system of claim 20 wherein at least one of the 
plurality of bit values in the category bit string is determined by at least one of a 

5 product feature option package and a standard product feature. 

25. The product comparison system of claim 17 wherein at least one of the a 
dynamic comparison module and the configuration engine is further operable to send 
the target product configuration and the competitor product configuration to the client 
computer system. 

10 26. The product comparison system of claim 17 encoded in a computer 

readable medium as instructions executable on a processor, the computer readable 
medium being one of an electronic storage medium, a magnetic storage medium, an 
optical storage medium, and a communications medium conveying signals encoding 
the instructions. 

15 27. The product comparison system of claim 17 wherein the target product is 

an automobile and the competitor product is an automobile. 
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510 



SIS 



SCO 





2001 Nevis Classic 2500 


2001 St. Kitts Quad Cab 4X4 


Features 


Extended Broadside 2WD 


1000 XT WRL 


Base MSRP 


22,000 


$20,910 ~ ~ 


Theft-Deterrent System 


Included \ 


Optional y 


Air Conditioning 


Included • V 


Optional \ 


Power Windows 


Included <yr\ 
Included . 


Optional 


Power Door Locks 


Optional 


Tilt Steering Wheel 


Included 


Optional 


Cruise Control 


Included 


Optional 


Leather- Wrapped, Steering Wheel 


Included 


Optional 


Power Exterior Mirror 


Included 


Optional 


Tachometer 


Included 


Optional 


Remote Keyless Entry 


Included 


Optional 


Dual Air Bags 


Included 


Included 


Intermittent Wipers 


Included 


Included 


Power Driver Seat 


Included 


Optional—— 53>2. 


Cassette Player 


Included 


Included 


Power Steering 


Included 


Included 


4 -Wheel Antilock Brakes 


Included 


Optional 


Automatic Transmission 


Included 


Optional 


Aluminum Wheels 


Included 


Optional 


Daytime Running Lamps 


Included 


Not Available — — 5 3 


AM/FM Stereo 


Included 


Included 


Rear/Second Row Folding Seat 


Included 


Included 


Equipped Total $ 


33,000 


$ 25,690 ( + NA ) * ? c 


- "V" ? : V»- ■ :•■> ' /"■ - - 


2001 Nevis Classic 2500 


2001 St. Kitts Quad Cab 4X4 I 


Specifications ! - ^ * 


Extended Broadside 2WD 


1000 XT WRL I 


Engine ' 






Engine Type 


5.0L V8 


5.2L V8 


Horsepower 


230 


230 


Torque (ft lbs) 


285 


300 


Dimensions - Exterior 






Length (inches) 


218.5 


244.1 


Width (inches) 


76.8 


79.3 


Wheelbase (inches) 


141.5 


154.7 


Dimensions - Interior 






Head Room Front/Rear (inches) 


40.0/38.0 


40.2/39.4 


Leg Room Front/Rear (inches) 


41.5/28.7 


41.0/31.6 


Shoulder Room Front/Rear (inches) 


65.0/67.6 


66.0/67.7 


Capacity 






Cargo Volume (cu ft) 


Not Listed 


Not Applicable 


Fuel Capacity (gal) 


25.0 


35.0 


Fuel Economy City (mpg) 


15 


13 


Fuel Economy Highway (mpg) 


19 


18 


Curb Weight Automatic/Manual (lbs) 


4396/Not Applicable 


4991/4950 


Warranty & Roadside Assistance 






Warranty (months/miles) 


36/36000 


36/36000 


24-Hour Roadside Assistance (months/miles) 36/36000 


36/36000 



Some option prices were not available for vehicle 

DPI: One or more of the options added is a dealer or port installed option. The price may vary depending 
on the dealership. 



N/A: One or more of the features added is included on the 
competitor's vehicle. 



vehicle but isn't available bn the 



Fzs. 5 



